This disclosure relates generally to network communications and more particularly to network communications in a cluster of computer systems.
In the Internet Protocol (IP) protocol, IP packets are routed from an originator through a network of routers to the destination. All physical adapter devices in such a network, including those for client and server hosts, are identified by an IP address which is unique within the network. One valuable feature of IP is that a failure of an intermediate router node or adapter need not prevent a packet from moving from source to destination, as long as there is an alternate path through the network.
In Transmission Control Protocol/Internet Protocol (TCP/IP), TCP sets up a connection between two endpoints, each identified by their respective IP address and port number pair. Unlike failures of an adapter in an intermediate node, if one of the endpoint adapters (or the link leading to it) fails, all connections through that adapter generally fail and must be reestablished. If the failure is on a client workstation, only a relatively few client connections are typically disrupted. However, an adapter failure on a server may mean that hundreds or thousands of connections may be disrupted.
One alternative to alleviate this situation is to configure a Virtual IP Address (VIPA). A VIPA behaves and is typically configured in the same manner as an IP address would be for a physical network adapter device. However the VIPA, being a virtual object, is not associated with a particular physical device. For example, when a TCP/IP stack on a server receives a networking packet that is destined for one of its configured VIPAs, the TCP/IP stack forwards the packet up the various TCP/IP layers to the destination application. Thus, if a particular physical adapter fails, the remaining attached routing network routes the VIPA-destined packets to the TCP/IP stack using an alternate route. While the VIPA is owned by the TCP/IP stack and reachable through any interface, the VIPA is not tied to any particular adapter. This allows network packets and User Datagram Protocol (UDP) datagram transmissions to be unaffected by a failure of a physical adapter owned by the TCP/IP stack as long as at least one other device remains operational for external connectivity to the same network.
Similarly, a program that access the TCP/IP stack may initiate an outbound connection, acting as a client rather than a server for the purposes of that particular connection. Such a program will typically not bind the socket to any particular local address before initiating the connection and normal TCP rules will use the address of the physical adapter on which the connection request is transmitted. As a result, the connection may be lost if that physical adapter fails while the connection is still active.
For outbound connections, the SOURCEVIPA function of the IP configuration process allows a VIPA to be associated with a group of physical adapters. This causes TCP/IP to use the VIPA instead of the adapter address when a program initiates an outbound connection without binding the socket to a particular IP address. This approach works well when a program is hosted on only one TCP/IP stack, or when the program receiving the connection request does not care what IP address is used for the source address of the connection request. There are some cases, however, where the traditional SOURCEVIPA approach does not meet the needs of a particular application. For example, some application pairs require both members to function as both client and server, where one partner establishes a connection to the other, which in turn establishes a connection back to the first. These applications often use the source and destination IP addresses to correlate the connections. Dynamic VIPA (DVIPA) addresses outages due to failures in a TCP/IP stack or an underlying operating system (OS) image. A DVIPA is a VIPA which can move from one TCP/IP stack to another, without operator intervention, in response to actions in an application or under the control of the OS or TCP/IP stack. Since DVIPAs may move from stack to stack, they typically cannot be used for SOURCEVIPA, which must generally be predictable to be useful.
A TCP connection is generally identified by a combination of source and destination IP address, and source and destination port numbers, known as the connection 4-tuple. Programs initiating outbound connections can rely on the TCP/IP stack to select a port that is not in use, referred to as an ephemeral port or sysplexport. With IP load balancing, such as Sysplex Distributor, the same IP address, referred to as dynamically routable VIPA (DRVIPA), can reside on multiple TCP/IP stacks. Unique connection 4-tuples can be configured using the existing SYSPLEXPORTS option of the VIPADISTRIBUTE configuration statement. However, the configuration process can be complex and error prone.
In current operation, specialized hardware referred to as a Coupling Facility (CF) includes a centralized shared table of sysplexports. Each computer system that participates in the sysplexports DRVIPA distribution registers with the CF for each DRVIPA. The CF then distributes blocks of sysplexports to the participating computer systems. The ports are used once and must be returned to the CF. In this architecture, each computer system maintains a table of it used ports, and when the table is full, the computer system returns the block of ports to the CF. Another block of ports may be requested. Each CF operation to distribute and manage the sysplexports tables uses at least one input/output (I/O) operation that is serialized by multiple locking operations.
Isolating the management of the sysplexports table to the Sysplex Distributor rather than sharing it among all computer systems in the Sysplex can eliminate the CF requirement, improve performance by reducing I/O operations, and remove serialization issues associated with the CF.